Many computing systems today utilize multiple processing units, resulting in a computer architecture generally referred to as multiprocessing. Multiprocessing systems are often used for transaction processing, such as airline and banking systems. Transaction processing refers generally to a technique for organizing multi-user, high volume, on-line applications that provides control over user access and updates of databases. A transaction refers to the execution of a retrieval or an update program in a database management system. Transactions originating from different users may be aimed at the same database records. This situation, if not carefully monitored, may cause the database to become "inconsistent". Where all transactions are executed one after the other, the database will remain in a consistent state. However, in a multiprocessing computing system, such serial I/O transaction execution may be wasteful of processing resources, as some host processors may be idle while another has multiple I/O requests queued.
In order to alleviate the wasting of processing resources, some prior art systems have implemented "interleaving" functionality, where the execution of transactions leaves the database in a consistent state. One way of preserving data consistency is to ensure that the interleaved transactions are equivalent to executing the transactions serially, which is referred to as serializable execution. This has been performed in the prior art by "locking" certain actions to be performed on a data item. In other words, a transaction may request that a data item be locked from being accessed or modified by other transactions, which results in the serialization of execution.
However, locking techniques may be complex, and can lead to problems such as "deadlock", where two transactions are waiting for each other to release locks and both cannot proceed. Furthermore, these prior art systems do not efficiently utilize processing resources in multiprocessing systems. For example, in some prior art systems, a host processor that received a request message from an I/O terminal was the same host that performed the corresponding database transaction. Therefore, all I/O requests are handled by "local" host processors, where "local" refers to those I/O requests made from I/O processors which are directly coupled to a particular host processor. For example, all I/O requests to or from a first I/O processor could be serviced by a first host processor, and could not be handled by remote host processors which are not directly coupled to the first I/O processor. In addition, where a failure occurs on any given host processor in the system, processing cannot continue for the pending I/O requests corresponding to that host processor until recovery is complete.
While I/O requests could be "passed" from a receiving local host to remote hosts, the overhead associated with such request routing is prohibitively complex and time consuming. Although data consistency can be preserved with some prior art request passing and/or locking techniques, they lack the efficiency and speed desired in I/O computing systems. Furthermore, some processing units in these prior art computing systems may be idle while others vigorously strive to sustain the demand for input/output.
The present invention allows a host processor, which is different than the host that receives the request message from a terminal, to perform the database transaction. This allows available host processors to share I/O tasks received at other host processors in the multiprocessing system, without requiring I/O request messages to be sent between various host processors. The present invention allows for the sharing of host processing resources for input/output transactions, thereby increasing overall system speed and reducing serialization complexities. The present invention therefore provides a solution to the aforementioned and other problems, and offers other advantages over the prior art.